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Abstract 

A laboratory distributed computer control teleoperator system is 
developed to support NASA’s future space telerobotic operation. This 
teleoperator system uses a universal force-reflecting hand controller in 
the local site as the operator’s input device. In the remote site, a PUMA 
controller receives the Cartesian position commands and implements 
PID control laws to position the PUMA robot. The local site uses two 
microprocessors while the remote site uses three. The processors com- 
municate with each other through shared memory. The PUMA robot 
controller was interfaced through custom made electronics to bypass 
VAL. 

In this paper, the development status of this teleoperator system 
is reported. The execution time of each processor is analyzed, and the 
overall system throughput rate is reported. Methods to improve the 
efficiency and performance are discussed. 
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1.0 INTRODUCTION 


It is hoped that in the future mankind will inhabit space on a permanent basis. 
Whether it be military crews operating space based offensive/defensive facilities or civilians 
living in space colonies, the habitation of space will require large amounts of construction 
and repair in space. For such tasks, it is preferable not to use astronauts since radiation 
hazards would limit the amount of time one person could be allotted EVAs (Extra Vehicular 
Activity). Also, there are some tasks where safety considerations would preclude using a 
man at all. In these situations it would be preferable to use some type of robotic device 
to achieve one’s objectives. 

Basically there are two types of robotic devices to use: autonomous and teleoperated. 
Autonomous systems require no human assistance to accomplish their task. After being 
informed of the task to perform, the autonomous system executes the task either from 
some preset repertoire of tasks or uses some type of artificial intelligence to determine how 
to tackle the problem. This requires that you have one or more of the following: 1) a 
very large set of pre-defined tasks to cover any and all eventualities, 2) a very good model 
of the environment, 3) a very powerful artificial intelligence computing capability, or 4) a 
good method of incorporating sensor data. This is a partial list of autonomous’ system 
requirements and still they may be difficult to meet. 

An alternative is a teleoperated system. A teleoperated system is basically a robotic 
device that is remotely controlled by a human operator. So we will depend upon a human 
mind to determine how to tackle a task. Still, for a human operator to properly direct a 
robot he will need sensors not only to provide him with a view of what the robot is doing, 
but also a feel for the forces the robot is both exerting and experiencing. 

In order to study some of these teleoperation issues we have constructed a teleop- 
eration system consisting of a force reflecting hand controller, a Unimation 560 robot, 
and five National Semiconductor microprocessors. The microprocessors are needed to per- 
form kmematic transformation and data communication since the FRHC (Force Reflecting 
Hand Controller) and robot are kinematically dissimilar and physically separated. With 

this system we will attempt to determine what defines “good” teleoperation and how to 
improve it. 


2.0 SYSTEM ARCHITECTURE 

The computing hardware of our system consists of five National Semiconductor 32016 
CPU development boards with N.S. 16081 floating point unit and an 10 megahertz clock 
(except the FRHC control CPU which has a 6 megahertz clock), two BLC-519 I/O boards, 
two 128 kilobyte RAM boards, and some ancillary electronics to interface with the FRHC 
(Force Reflecting Hand Controller) and the Unimation PUMA 560 robot. 

All of the computing hardware is contained in two Multibus Chassis. See Figure 1. 
More specifically, the various components perform the following tasks: 
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Figure 1 . System Architecture 


( 


LOCAL NODE 



FRHC 


FRHC 

Electronics 

















1) Two communications CPUs, one located in each chassis (node), that decide what data 
to send, retrieve that data from off board RAM, assemble that data into a buffer and 
send it over a parallel link. Conversely, when a communication CPU is receiving, it 
determines what data it is receiving, and places that data in the appropriate locations 
in off board RAM. The local communication CPU also contains the menu through 
which system parameters can be altered. 

2) One FRHC control CPU that interprets the encoder values of the FRHC and converts 
them into joint angles, from these joint angles the Cartesian position and orientation 
of the end of the FRHC is determined (i.e. the FRHC T6 matrix), for position control. 
For rate control, the deviation of the FRHC from some neutral position is used to 
generate rate commands. This CPU also calculates the force feedback to backdrive 
the FRHC, whether we are in the rate or position mode. 

3) Two BLC-519 I/O boards that have the 8 bit parallel I/O ports that the commu- 
nications CPUs actually use to send and receive data between the remote and local 
nodes. 

4) Two BLC-0128A 128 kilobyte off board RAM boards, that are used to hold all infor- 
mation that is shared between processors within a node and to hold all information 
shared between nodes. Each specific piece of stored information is held at a specific 
address known to all the CPUs. 

5) The PUMA robot control CPU does the inverse kinematics and the forward kine- 
matics of the robot, along with compensation for an end effector, and workspace 
transformations. 

6) Actual interfacing with the robot is accomplished by the PUMA interface CPU. It 
sends joint angle commands to the robot, reads the current robot joint angles, cali- 
brates the robot, and performs the setpoint interpolation. 

7) The PUMA electronics provides the servo power to the robot and has six Motorola 
6503 joint microprocessors that actually perform the low level robot servo control. 

8) FRHC electronics allows us to read the potentiometers of the FRHC’s six joints and 
to supply current to the motors attached to the six joints for force feedback. 

9) The PUMA interface electronics facilitates direct communication with the six 6503 
joint microprocessors. 

PUMA Interface Electronics 

Our interface design approach is to by-pass Unimation’s LSI-11 resident VAL-II and 
to simulate Unimation’s interface to the DRVll in the PUMA arm controller by using two 
Intel 8255 Programmable Peripheral Interface(PPI) adapters. Port A, B, and C on the 
PPI are used for data input, output and handshake, respectively. Mode 1 is selected as the 
port mode. To read or write the data/commands from/to the joint processors, a request 
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signal hasent through handshake line. The data sampling rate and the position 
commandng rate is hence dependent on the high level processor cycle rate. 

The 1 servo co mm ands issued from high level processor are decomposed into 
digital semands acceptable by PUMA joint processors. The low level servo com- 
mands ardy the following four routines coded in ”C”: 

a) read_sint, command, data) - reads encoder/current value, depending on the 
commm the specified joint. 

b) readjommand, data) - reads an array of encoder/current values from all six 
joints 

c) writejint, command, data) - write set points/motor currents, depending on 
the co, to the specified joint. 

d) writejommand, data) - write an array of set points/motor currents, to all six 
joints neously. 

Embe< the same interface software routine, those four routines interpret the 
commands form proper handshakes to read/write the data/digital servo commands 
to/from thA. interface. 


3.0 SYSTETTROL MODES 
Control Mcration 

The eifeoperation system is constituted of three control loops: the supervisory 
control loojjcal control loop and the remote control loop. The supervisory control 
loop includ^perator, the visual and audio feedback, and menu-driven commands. 
Through refection, the operator can switch the control mode, change the control 
parameters anitor the control status. The local control loop consists of the force 
reflecting hurdler and the local processors. The remote control loop is formed by 
the sensorsanipulator and the remote processors. High level information, such as 
the Cartesicions /velocities and the control mode words, are exchanged between the 
local and thte control loops. 

In the control loop, the low level servo commands generated by the remote 
processors a>d to the PUMA’s joint processors through the interface board in the 
PUMA contnit. Since the PUMA joint processors control the joint motors either 
in “position or in “current mode,” the servo commands generated by the processor 
are also bas<he above two modes. In “position mode” the joint processor accepts 
encoder set and implements PID control. In “current mode” the motor torque 
commands acted by the joint processors. Currently, the PUMA interface processor 
takes advant the joint processor PID control capability and sends only encoder set 
points to therocessors. The direct joint motor control that sends current commands 
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to joint processors is not currently implemented because 1) the interrupt-driven interface, 
which facilitates the high bandwidth PD or PID servo control, is not installed; 2) the 
PUMA velocity needed for PD or PID control is also not available. 

All of the following three major system control modes result in the position commands 
which servo the PUMA arm in its “position mode”: 

1) Position control mode. By reading the pots from the hand controller interface, the 
joint angles are computed. Forward kinematics of the hand controller is then per- 
formed to determine the end-point position and orientation in Cartesian coordinates 
which is commonly referred to as the T6 matrix. Upon receiving the end-point posi- 
tions of the hand controller through the parallel line, the remote processor performs 
the inverse kinematics of the PUMA to determine the desired joint positions. The 
desired joint set points in encoder values tire then calculated and sent to the PUMA 
joint processor interface. The current PUMA joint position is also read by the remote 
processor. From this, robot forward kinematics are done to calculate the position and 
orientation of the robot’s endpoint. This information is transmitted back to the local 
node. The position error between the hand controller position and PUMA position 
are then computed and used to back drive the hand controller. 

2) Rate control mode. In rate control mode, the hand controller is utilized as a joystick- 
type input device, in which the spring effect is generated by the software. The joy- 
stick s displacement from its nominal position determines the rate. By integrating 
the rate, the local processor yields the aggregated positions which are then sent to 
the remote site. A small deadband was set around the nominal position of the hand 
controller to ensure no position output when the hand controller rests in the neigh- 
borhood of its nominal position. Since the feedback position is not processed in this 
mode, the throughput is slightly faster than in the position mode. 

3) Mixed mode. In this mode, the translational axes operate in rate control mode while 
the rotational axes operate in position control mode. This mode would allow the 
operator to quickly move PUMA arm in the work space while maintaining the same 
orientation of the hand controller. 

The above three control modes are actually commanding the PUMA arm’s movement, 
and are therefore categorized as operation modes. The following are three other non- 
operation modes, in which the PUMA arm is “quiescent”: 

1) Start mode. This is the first mode entered upon turning on the power. In this mode, 
the initialization, health and status checking take place. 

2) Index/menu mode. Since the work volume of the hand controller is much smaller than 
that of the PUMA arm, one of the means to augment the hand controller positioning 
capability is to use indexing. This mode allows the hand controller to move to a new 
position while the PUMA arm is frozen. The teleoperation resumes after a key on the 
keyboard or a button on the hand controller is hit. Another means of augmenting the 
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hand controller positioning capability is by using scaling factors. The movement of 
the PUMA arm can be amplified to a larger motion or confined to a smaller motion by 
the proper selection of scaling factors in the menu. The first one is for gross movement 
and the second one is for dexterous positioning. The scaling factors can be applied to 
both position control mode and rate control mode. 

3) Quit mode. This mode is entered through menu selection. In this mode, procedures 
including robot servo power shut off, return of confirmation messages, etc., must be 
exercised prior to system shut- down. 


Control Mode Transition 

Since the robot is frozen during index mode, it is used as a natural gateway for 
mode transition. After startup, the system will default into the index/menu mode. From 
index/menu mode, the operator can transit into any of the following modes: 

a) Quit mode - By menu selection. 

b) Position mode - By depressing the index button on the handgrip of the hand controller. 

c) Rate mode - By depressing the index button after selecting the rate mode from the 
menu. 

d) Mixed mode - By depressing the index button after selecting the mixed mode from 
the menu. The mode transition diagram is shown in Fig. 2. 

When exiting the index mode, the current PUMA position is stored and the trans- 
lational bias between the new hand position and PUMA position is calculated. Provided 
that the indexing is also applicable to the rotation, as the operator desires, the rotational 
bias has to be calculated. The translational vector of the subsequent position commands 
are then added to the stored PUMA position to yield new PUMA position commands. 

By using Denavit-Hartenberg notations, the translational bias is computed as follows: 


(mT) = CT) (Sir) (ilT)" 1 


R P 
0 1 


( 1 ) 


where the (JqT) denotes the transformation from aO (base of robot arm) to hO (base 
of hand controller). Similarly, (“gT) ' s the current PUMA position (i.e., T6 matrix) w.r.t. 
its own base reference. (£|T) is the hand controller’s new position w.r.t. its own base 
reference, and (£|T) is the coordinate transformation between PUMA arm’s last joint and 
the hand controller’s hand grip. The R matrix in (^qT) results in Eq. (1) being replaced 
by a 3x3 matrix, which is pre-determined to correct the coordinate disparity between hand 
controller base and robot base. The P_ vector in (£qT) represents the translational bias. 
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Figure 2. Mode Transition Diagram 


u 





The rotational bias is calculated as 


Gt„r) = (f s T)-'C n T) (2) 

where (06*^) is determined by 

(Sl„r) = a° 0 T) (J|r) (S|r) (3) 

and the (£' qT ) matrix is derived form Eq. (1). If the index on rotation is not desired, the 
R matrix in can be replaced by an identity matrix /. 

The subsequent position commands (T6) after indexing is then computed as follows: 

G8. T) = Ct) (Sir) (Sir) cS.r) (4) 


4.0 ROBOT KINEMATICS 

In order to determine the position and orientation of the last link of the robot in 
Cartesian space, reference frames were assigned to each link of the robot, using Denavit- 
Hartenberg notation. See Figure 3. Six transformation matrices J 1 T were then deter- 
mined that relate the reference frame of link i to link t — 1, which tire a function of the 
joint angle of that link. Multiplying these six matrices, i.e., 

\T\T\T\TiTlT = %T (5) 

yields a qT matrix, a 4x4 matrix that contains both the orientation and position of the 
reference frame of the last link with respect to some arbitrary reference frame. 
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where R is the orientation matrix and P is the position vector. This generation of a gT 
given the joint angles of the robot is referred to as the forward kinematics calculation. 

There is one problem with this formulation thus far and that is that the reference 
frame of the last link is actually embedded within the robot wrist while what is desired is 
the position and orientation of the tip of an end effector. See Figure 4. Therefore we must 
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Figure 4. Robot T6 Frame Versus T7 Frame 
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multiply the gT matrix by a transformation that describes the position and orientation of 
the tip of the end effector with respect to the %T reference frame. 

?T =qT * E where E is also a 4x4 matrix. (7] 

Now that we have described how to obtain the position and orientation of the robots 
end effector given the robots joint angles, the more difficult task is to determine the robot 
joint angles that will yield a specified position and orientation of the end effector tip. This 
is referred to as the inverse kinematics calculation. By successively premultiplying both 
sides of equation by the inverse of the leading term on the left hand side we obtain the 
following 


\T\T\T\T\T = \T- l {lT) ( 8 ) 

\T\TiT\T = \T-\°T- *)(2D (9) 

3 r 4 r | r = 2 r -i ( i T -i)(0 r -i)(0 r) (1Q) 

\tIt = jr-^lr-^dr-'j^r-^tgr) (n) 

It = (12) 


If we equate terms in equations (8) through (12) the angular values of the six PUMA 
joints can be found in terms of the Cartesian position and orientation [2]. Again, there 
is the problem that final solution obtained will be in terms of the components of the 
qT matrix, whereas what is actually specified is the jT matrix (i.e., the position and 
orientation of the tip of the end effector). From equation (7) we can obtain the intermediate 
&T matrix from the actual ^T matrix by postmultiplying by the inverse of the end effector 
transformation so that 

gr = ;r.fr‘ (i3) 


5.0 COMMUNICATIONS 

While there are two distinct computing nodes, only one node, the local node, allows 
the user to interface with the system. It is through the local node that the user enters 
all appropriate data and receives any information from the system. Associated with the 
local communications processor is a menu. When the two nodes are communicating via 
the remote and local communication CPUs the user hits the “escape” key on the terminal 
attached to the local communication processor. This stops communication and enters the 
user into the index/menu mode. By now typing “m” on the keyboard, the user brings 
up the menu which has a hierarchical tree structure. Once inside the menu, the operator 
can call up sub-menus that change such system parameters as operational mode, motion 
scaling factor, robot end effector length, etc. All data to be shared by processors within 
a node as well as data to be used by processors within another node are stored in off 
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board RAM. When the user enters changes from the menu the appropriate data is also 
changed in off board RAM. Upon exiting the menu the user can re-start the inter node 
communication by simply hitting the "return” key on the terminal. 

Since the local and remote node are located in two different chassis, a way was needed 
to allow the two nodes to communicate with one another. Another problem was that 
depending on the operational mode different data would be passed between the nodes. For 
example in position mode you would want the local node to send a position and orientation 
matrix, while in joint mode (not implemented yet) you would only want to send six joint 
angles. 

Communication is achieved with two sets of boards, one set resides in each chassis. A 
communication board set consists of one 32016 CPU board and one BLC-519 I/O board. 
The BLC-519 has 9 eight bit parallel communication channels and uses the Intel 8255 
chip for I/O. Each I/O board has three ports where each port contains three parallel 
communication channels. Currently, the I/O boards operate in mode 1, which simply 
means channel A of the port is used for local to remote node communication, channel B 
of the port is used for remote to local node communication, and the eight lines of channel 
C are used for hand-shaking. 

Within the framework of the C programming language we set a pointer equal to the 
address of the appropriate channel of the appropriate port of the I/O board. Then by 
setting the value of whatever the pointer points to we can send a byte of data over the 
parallel communication link. Likewise, by reading the value of what the pointer points to, 
we can read what has been sent over the parallel link. Communication is synchronized by 
the use of a read acknowledge line and a write acknowledge line. If a sender is to send more 
than one byte of information, it waits for a read acknowledge signal from the receiving 
side before sending each subsequent byte. The read acknowledge is set by the receiver 
when its CPU board reads what has been sent to its I/O board. Similarly, the receiver 
CPU will not read what its I/O board has until it receives a write acknowledge. A write 
acknowledge is set whenever the sender places a byte of information on its parallel port. 

Data sent from the local node to the remote node will always consist of a mode word, 
local status word, and a remote command word, each being two bytes in length. The 
bits of the mode word indicate what operational mode the system is currently in, whether 
indexing is on or not, and whether any parameters have been changed. Similarly the bits 
of the local status word show the local status, while the bits of the remote command word 
indicate the functions the remote side is to perform. See Figure 5 for a definition of the 
bits. Other data to be sent will consist of one or more of the following items FRHC T6 
matrix, FRHC Cartesian velocity, FRHC joint angles, robot end effector length or FRHC 
frame vs. robot frame difference. The last two items will be sent only once after the 
value of either has been changed by the operator. By deciphering the mode word the 
local communications CPU determines which data to retrieve from shared RAM and send 
over the parallel communications link. For example if the mode is joint mode and the 
parameter change bit is set the local communications CPU will retrieve the mode word, 
local status word, remote command word, FRHC joint angles, robot end effector length, 


13 


- node Control Word 


Bit 

Control Mode 

0 

Position control 

1 

Rote control 

2 

Current control (future u? 

3 

Joint control (future use) 

4 

Index mode -On 

5 

Rotation indexing - On 

to 1 4 

Unused 

15 

Parameter change 
indicator 


Robot Status Word 


Bit 

Meaning 

0 

Calibration status 

1 

Servo pover on/off status 

2 

Joint limit violation in in- 


verse kinematics solution 

3 

Gripper open or closed statue 

4 

Robot processor (MACS) error 

5 

Robot UC error 

6 

Comm processor error 

7 

Sensor processor error 


- FRHC 

Command Word 


Bit 

Commend 

0 

Calibration cm'd 

1 

Servo power on /off cm’d 


1c - Robot 
Command Word 


Bit 

Commend 

0 

Calibration crn'd 

1 

Servo pover on /off cm'd 

2 

Unused 

3 

Gripper open/close cm’d 


- FRHC Status Word 


Bit 

Meaning 

0 

Calibration statue 

1 

Servo pover on /off statue 

2 

Unused for nov 

3 

Unused for nov 

4 

HACS error 

5 

MIS error 

6 

Comm processor error 

7 

Graphics processor error 


Figure 5. Mode Status Command Word Bit Definition 
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and the FRHC vs. robot frame difference. These data items are assembled into a data 
buffer and sent byte by byte to the remote communications CPU. The first byte sent is a 
number telling how many bytes of information are contained in the data buffer. Held in 
the first two bytes of the data buffer is the mode word. Upon deciphering the mode word 
the receiving node then knows what data is held in the buffer. This data is then deposited 
in the appropriate places in shared RAM. 

The format of the data held in the buffer is the actual binary pattern residing at the 
memory address that corresponds to the variable you have selected. For unsigned integer 
variables such as the mode and status word, it is the expected binary representation. 
However, for non-integer numbers such as the robot end effector or the T6 matrices, the 
memory location corresponding to a variable represents the non-integer variable as a 64 
bit double precision number in the National Semiconductor Series 32000 floating point 
format. The 64 bit field contains such information as the sign of a number, the value of 
its exponent and the value of its mantissa. While non-integer information is originally 
held in a 64 bit field (double precision number) it is first converted to a 32 bit field (single 
precision number) before placing it in the data buffer. Again, the 32 bit field of the single 
precision number still contains such information as sign, mantissa, and exponent. The 
double precision to single precision conversion speeds overall parallel communication at 
the price of a slight reduction in the accuracy of the numbers transmitted. 

In sending the literal contents of a variable’s address in memory in floating point 
format we greatly increase the overall communication throughput, as compared to the 
option of sending numbers over in ASCII format. 

Embedded within the communication software is also a provision for checking the 
health of each processor. Associated with each processor is a 32 bit long error word. Each 
bit in the error word corresponds to a specific problem in a specific processor. When a 
processor detects some problem within itself it then sets the appropriate bit with its error 
word. Of course these errors must be of a non-catastrophic nature, because if it were to 
cause a processor to “die” then that processor would be unable to set a bit in its error 
word. If the remote communications processor finds any of the remote node error words 
non-zero (i.e., some type of error) it sets the appropriate bit in the remote status word 
and ships any non-zero error words to the local node. By looking at the bits of the error 
word the operator can then tell what error has occurred in what processor and take any 
appropriate action. 


6.0 SETPOINT INTERPOLATION 

When both the local and remote nodes first became operational it was found that 
the robot motion, when following position commands generated by the FRHC, was un- 
satisfactorily jumpy. Upon comparing the cycle rates of the local and remote nodes it 
was found that the FRHC control CPU was running faster than the PUMA robot control 
CPU. Since the two processors were running asynchronously this meant that occasionally 
the robot control processor would miss a position command from the FRHC control CPU. 
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n an a ttemptooth out the position commands the robot tries to servo to, a spline 
t was made s even if occasionally a point was missed the motion would be smooth 
and continuouead of smoothing out the FRHC Cartesian commands it was decided 
to smooth outesults of the robot’s inverse kinematics (i.e., a joint space position 
composed the s six joint values) from an FRHC Cartesian command. 

It was de<to use a cubic parametric that is both smooth and continuous with 
e sec °nd dere of the curve at the spline knots (the original points we wish splined 
together) beingrarily set to zero. Referring to Figure 6 where pi, p2, and p3 are the 
hree joint spaeition vectors we want splined together and Tl, T2 ? and TZ are the 

corresponding tat vectors, then a; space curve through p2 and p3 is expressed bv the 
equation — — 

p(u) = A + Bu + Cu 2 + Du 3 ( 14 ) 


where currently u < 1. From the boundary conditions we get the following relation- 
ships: 


p(0) = p2 

p(l) =p3 


dp 

du 


= T 2 

u=0 


dp 

du 


l 


= TZ 


p"(0) = p"(l) = 0 


(15) 

(16) 

(17) 

(18) 
(19) 


Using these reitionships, we can easily determine that from equation (14) 


A = p2 


(20) 


B = T2 (21) 

C = Z*{pZ-p2) -2*T2-TZ (22) 

D = 2 * (p2- pZ) + T2 + TZ (23) 


Further we can determine that 


T2\i\ - (~ 6 * (p2 [t[ ~ P 1 !*] + 12 * (p3[i] - pl[t]) - 6 * (p3[tj - p2[t]|) 

12 

T3[t] = ( 3 * (p2[i\ - pl[t] - 6 * (p3[t] - pl[tj) + 21 * (p3[tj - p2[tj)) 
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where i = 0, 1,2, 3, 4, 5 are the six components of a robot joint space position, pi is the 
third most recent result of the robot inverse kinematics, p2 is the second most recent 
result of the robot inverse kinematics and p3 is the most recent result of the robot inverse 
kinematics. 

Now, using equation (14) we generate seven spline fits that are equally spaced between 
u = 0.5 and u = 1.5. So, the spline fit starts midway between p3 and p2. It then follows a 
smooth curve through p3 and ends at a predicted joint space point halfway past p3. 



Figure 6. Two dimensional representation of six dimensional space curve 
7.0 SYSTEM THROUGHPUT 

There are primarily eight tasks that the PUMA robot control CPU performs in a 
serial fashion. 

1) Retrieval of FRHC T6 from shared RAM: This process takes 0.000143 seconds which 
is equivalent to a rate of 6976.7 Hertz. 

2) Workspace adjustment for use in forward kinematics: This process takes 0.001533 
seconds which is equivalent to a rate of 6522 Hertz. 

3) Forward kinematics: This process takes 0.006 seconds which is equivalent to a rate of 
166.6 Hertz. 

4) End effector compensation for forward kinematics: This process takes 0.00020 seconds 
which is equivalent to 5000 Hertz. 

5) Placement of PUMA T6 in shared RAM: This process takes 0.0001366 seconds which 
is equivalent to a rate of 7317 Hertz. 


17 


6) Wor.djustment for use in inverse kinematics: This process takes 0.00102 sec- 
onds equivalent to a rate of 980 Hertz. 

7) End compensation for inverse kinematics: This process takes 0.0001925 sec- 
ondss equivalent to a rate of 5194 Hertz. 

8) Invenatics: This process takes 0.01071 seconds which is equivalent to a rate 
of 92. 

Sum these times and including a few other smaller processes that are also part 
of the rolrol CPU computational workload yields a cycle time of 0.02267 seconds 
which is nt to a rate of 44 Hertz. 

Comion time to send a FRHC T6 matrix and receive a PUMA T6 matrix is 
0.014 secdch is equivalent to a rate of 71.4 Hertz. 

The .ontrol CPU cycles at a rate of 25 Hertz in position mode and 27 Hertz 
in rate mle times of 0.04 seconds and 0.037 seconds respectively). This CPU had 
a 6 megaick rate. 


Sum: of these times in position mode, the minimum amount of time it takes 
to send and from the FRHC, have the command transmitted to the robot, send 
the roboti back to the local node and generate position error based force feedback 
in the FR.0767 seconds, which is equivalent to a rate of 13 Hertz. 

All oftware was coded in the high level programming language C, however, a 
rather inecross compiler (National Semiconductor’s GCS) was used. 

8.0 CON<NS AND FUTURE WORK 

This .resents the current framework of our teleoperator system development. 
Position <of a PUMA robot bypassing VAL and using a distributed computing 
system apitisfactory, albeit with some limitations: 

1) SinceMA joint processors’ PID control parameters are proprietary information 
and Qe easily accessed and altered, the control flexibility is hence somewhat 
handi 

2) The loint rate information, which is crucial for bilateral servo control, is also 
not a' 

3) The Ciand controller electronics do not provide velocity information, and the 
velociiation by software is not very accurate. 

A nevrsal Controller (UC) is under development to replace both of the hand 
controller <ics and the entire PUMA controller in the near future [ 1 ] . This UC shall 
provide ea ss to the control parameters and easy adaptation of different control 
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methods. The limitations cited above that appeared in the current teleoperator setup 
shall be alleviated when the UC is implemented. 

The goal of our teleoperator development is to realize a higher throughput bilateral 
servo control system. The following work is planned to reach this goal: 

1) Direct current control, instead of position control, shall be implemented for force or 
force/position control of the robot arm. 

2) Robot dynamics, in addition to kinematics, shall be implemented. 

3) Information from robot force torque sensors shall be included in the calculation of 
hand controller force feedback. 

4) To attempt an increase in system throughput, interrupt driving and synchronization 
of the distributed processor shall be explored. 

5) Obtain a more efficient cross compiler. 
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